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APPELLANT'S BRIEF 



Commissioner for Patents: 

This brief is in furtherance of the Notice of Appeal, filed in this case on 
September 15, 2009. The fees required under Section 41.20(b)(2), and any required request for 
extension of time for filing this brief and fees therefor, are dealt with in the accompanying 
transmittal letter. 



A. I. REAL PARTY IN INTEREST 

The real party in interest is ST-Ericsson SA, which has an address at 39 Chemin du 
Champ des Filles, 1228 Plan-Les-Outes, Geneva, CH. 
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B. II. RELATED APPEALS AND INTERFERENCES 

Appellant, Appellant's legal representative, and the real party in interest are 
unaware of any appeal or interference which may be related to, directly affect, be directly 
affected by, or have a bearing on the Board's decision in the present appeal. 

C. III. STATUS OF CLAIMS 

Claims 1-23 are pending and stand rejected. All pending claims attached hereto 
as a Claims Appendix, and reflect the amendments entered by the Examiner for purposes of 
appeal. As discussed in more detail below, an amendment to correct a typographical error in 
claim 20 was filed after the final rejection and entered by the Examiner for purposes of appeal. 
All pending active claims are attached hereto as Appendix A, and reflect the amendment entered 
by the Examiner for purposes of appeal. 

Claims 1, 3-8, 10-20 and 22 stand rejected under 35 U.S.C. 103(a) as obvious 
over U.S. Patent Application Publication No. 2004/0264397 Al by Benveniste in view of U.S. 
Patent Application Publication No. 2004/0103282 Al by Meier. Claims 2, 9, 21 and 23 stand 
rejected under 35 U.S.C. 103(a) as obvious over Benveniste and Meier in view of U.S. Patent 
Application Publication No. 2003/0126244 Al by Smith et al. 

The rejections of claims 1-23 are appealed. 

D. IV. STATUS OF AMENDMENTS 

An amendment after the final Office Action was submitted on August 26, 2009. 
The amendment addressed informalities in claim 20. The Examiner entered the amendment to 
claim 20 for purposes of appeal in an Advisory Action mailed on September 8, 2009, in which 
the Examiner disagreed with the arguments made in response to the final Office Action. The 
Examiner is thanked for entering the amendment for purposes of appeal. 

E. V. SUMMARY OF CLAIMED SUBJECT MATTER 

The application is a conversion of PCT Application No. PCT/IB04/52343 filed 
November 8, 2004 into a U.S. National Application. 
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The present application includes 4 independent claims, all of which are being 
appealed. The following summary discusses the subject matter of the independent appealed 
claims along with citations to corresponding portions of the specification and drawings per 37 
C.F.R. § 41.37(c)(l)(v). The citations below are provided to illustrate specific examples and 
embodiments of the recited language, and are not intended to limit the claims. None of the 
independent claims involved in the appeal or dependent claims argued separately includes means 
plus function elements or steps plus function elements as permitted by 35 U.S.C. § 112, sixth 
paragraph, and thus no corresponding summaries related to such means plus function elements or 
step plus function elements are included. 

It is believe that the claimed invention will be more easily understood if some 
embodiments shown in the figures of the present application are discussed first. Following that 
discussion is a presentation of the independent claims with reference to the figures and 
specification. Of course, the parentheticals shown in claims 1, 8, 18 and 22 are intended to show 
support for the claimed elements, and are not intended to limit the claims only to the 
embodiments referenced in the parentheticals. 

Figures 4 through 6 illustrate embodiments of methods of determining when to 
provide service to client devices operating in power save mode in a wireless network. Figure 4 
appears below. 
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FIGURE 4 

As illustrated, a service request is received from a client at 410. A determination 
is then made at 420 as to whether the request is for scheduled service or for unscheduled service. 
This may be done by setting a schedule bit in the service request, as illustrated in Figure 3B, 
which appears below. 
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FIGURE 3B 



If the request is for scheduled service, the request may then be processed 
according to the embodiment of a method set forth in Figure 5, reproduced below. 
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FIGURE 5 

As illustrated, it is determined whether the request for scheduled service will be 
accepted at 510. If the request is accepted, it will be provided as requested or provided under a 
modified schedule, and the client will be provided with an indication of the schedule under 
which the service will be provided. See 460, 465 and 470. If the request is denied, the denial 
will be recorded and the client will be provided with an indication that the request has been 
denied. See 520, 530. 
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If the request is for unscheduled service, the request may be processed according 
to the embodiment of a method set forth in Figure 6, reproduced below. 
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FIGURE 6 

As illustrated, it is determined whether to honor the request for non-scheduled 
service (430). If the request is to be honored, the client is provided with an indication that the 
request will be accommodated (435). If it is not to be honored, it will be determined whether the 
request will be accepted (630). If the request is not accepted, the client will be provided with an 
indication that it was not accepted (530). If the request is to be accepted, a schedule will be set 
up and the client will be provided with an indication that the request will be accommodated with 
a schedule (440, 450). 

Figure 7, reproduced below, illustrates a system 700 in a wireless network which 
is configured to determine when to provide service to client devices 701. The system includes a 
processor which, for example, is configured to execute instructions to carry out methods of 
determining when to process client requests, such as the methods illustrated in Figures 4-6. 
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FIGURE 7 

Independent Claim 1 : 

Independent claim 1 is directed to a method to determine in a network component 
(Fig. 7, 700) when to provide service to client devices (Fig. 7, 701) operating in power-saving 
mode in a wireless network (Fig. 7), the method comprising: 

receiving requests for service from respective ones of said client devices (Figs. 4- 
6, 410), the received requests for service including a scheduled request received from a first one 
of the client devices (Figs. 4 and 5, 460) and an unscheduled request received from a second one 
of the client devices (Figs. 4 and 6, 430), said network component being informed of said 
scheduled request by a field of a traffic specification format being set to a first value (Fig. 3a, TS 
INFO; Fig. 3b, SCHEDULE; Figs. 4-6, 420; page 4, paragraphs 20 and 21), said network 
component being informed of said unscheduled request by said field of said traffic specification 
format being set to a second value different from said first value (Fig. 3a, TS INFO; Fig. 3b, 
SCHEDULE; Figs. 4-65, 420; page 4, paragraphs 20 and 21); 

determining an ability to accommodate said received requests for service (Fig. 4, 
460, 465, 430; Fig. 5, 510, 460, 465; Fig. 6, 430, 630; page 4, paragraph 21 to page 5, paragraph 
23; page 6, paragraphs 27 and 28); and 
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providing respective indications of the ability to accommodate said received 
requests for service to the first and second ones of said client devices (Fig. 4, 470, 450, 435; Fig. 
5, 470, 530; Fig. 6, 530, 450, 435; page 4, paragraph 21 to page 5, paragraph 26; page 6, 
paragraphs 27-29). (See also Figures 3a through 6 and the descriptions thereof on pages 4-6). 

Independent Claim 8: 

Independent claim 8 is directed to a device (Fig 7, 700) to determine when to 
provide service to client devices (Fig. 7, 701) operating in power-saving mode in a wireless 
network (Fig. 7), said device comprising: 

a memory (Fig. 7, 704); 

a processor (Fig. 7, 703) in communication with said memory, said processor 
operable to execute code to: 

receive requests for service from respective ones of said client devices (Figs. 4-6, 
410; page 8, paragraph 34), the received requests including a scheduled request received from a 
first one of the client devices (Figs. 4 and 5, 460) and an unscheduled request received from a 
second one of the client devices (Figs. 4 and 6, 430), said device being informed of said 
scheduled request by a field of a traffic specification format being set to a first value (Fig. 3a, TS 
INFO; Fig. 3b, SCHEDULE; Figs. 4-6, 420; page 4, paragraphs 20 and 21), said device being 
informed of said unscheduled request by said field of said traffic specification format being set to 
a second value different from said first value (Fig. 3a, TS INFO; Fig. 3b, SCHEDULE; Figs. 4- 
65, 420; page 4, paragraphs 20 and 21); 

determine an ability to accommodate said received requests for service (Fig. 4, 
460, 465, 430; Fig. 5, 510, 460, 465; Fig. 6, 430, 630; page 4, paragraph 21 to page 5, paragraph 
23; page 6, paragraphs 27 and 28); and 

provide respective indications of the ability to accommodate said received 
requests for service to the first and second ones of said client devices (Fig. 4, 470, 450, 435; Fig. 
5, 470, 530; Fig. 6, 530, 450, 435; page 4, paragraph 21 to page 5, paragraph 26; page 6, 
paragraphs 27-29). (See also Figures 3a through 7 and the descriptions thereof on pages 4-8). 
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Independent Claim 18: 

Independent claim 18 is directed to a processor (Fig. 7, 703) within a network 
component (Fig. 7, 700) to determine an ability of said network component to honor requests for 
service received from respective client devices (Fig. 7, 701), said processor being configured to 
execute code to cause the network component to: 

review an operating state of said network component (Figs. 4-6, 430, 465, 510, 
630; page 4, paragraph 21; page 5, paragraphs 23, 25 and 26; page 6, paragraph 27); 

review said requests for service (Figs. 4-6, 410; page 8, paragraph 34), the 
requests for service including a scheduled request received from a first one of the client devices 
(Figs. 4 and 5, 460) and an unscheduled request received from a second one of the client devices 
(Figs. 4 and 6, 430), said network component being informed of said scheduled request by a field 
of a traffic specification format being set to a first value (Fig. 3a, TS INFO; Fig. 3b, 
SCHEDULE; Figs. 4-6, 420; page 4, paragraphs 20 and 21), said network component being 
informed of said unscheduled request by said field of said traffic specification format being set to 
a second value different from said first value (Fig. 3a, TS INFO; Fig. 3b, SCHEDULE; Figs. 4- 
65, 420; page 4, paragraphs 20 and 21); 

accommodate said requests for service, with modification when necessary, when 
said operating state indicates that said requests for service are able to be accommodated (Fig. 4, 
465, 440, 450, 435; Fig. 5, 465; Fig. 6, 440, 450, 435; page 8, paragraph 34; page 12, original 
claim 18); and 

provide respective indications of said accommodation to said first and second one 
of the client devices (Fig. 4, 470, 450, 435; Fig. 5, 470, 530; Fig. 6, 530, 450, 435; page 4, 
paragraph 21 to page 5, paragraph 26; page 6, paragraphs 27-29). (See also Figures 3a through 7 
and the descriptions thereof on pages 4-8). 

Independent Claim 22: 

Independent claim 22 is directed to a computer readable media (Fig. 7, 704, 787, 
783; page 7, paragraph 32 to page 8, paragraph 33) whose contents cause a processor (Fig. 7, 
703; page 7, paragraph 32 to page 8, paragraph 33) to execute instructions to cause a network 
component (Fig. 7, 700) to: 
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receive requests for service from client devices (Figs. 4-6, 410; page 8, paragraph 
34), the received requests including a scheduled request received from a first one of the client 
devices (Figs. 4 and 5, 460) and an unscheduled request received from a second one of the client 
devices (Figs. 4 and 6, 430); 

become informed of the scheduled request based on a field of a traffic 
specification format being set to a first value (Fig. 3a, TS INFO; Fig. 3b, SCHEDULE; Figs. 4-6, 
420; page 4, paragraphs 20 and 21); 

become informed of the unscheduled request by said field of said traffic 
specification format being set to a second value different from said first value (Fig. 3a, TS INFO; 
Fig. 3b, SCHEDULE; Figs. 4-6, 420; page 4, paragraphs 20 and 21); 

determine an ability to accommodate said received requests for service (Fig. 4, 
460, 465, 430; Fig. 5, 510, 460, 465; Fig. 6, 430, 630; page 4, paragraph 21 to page 5, paragraph 
23; page 6, paragraphs 27 and 28); and 

provide respective indications of the ability to accommodate said received 
requests for service to the first and second ones of said client devices (Fig. 4, 470, 450, 435; Fig. 
5, 470, 530; Fig. 6, 530, 450, 435; page 4, paragraph 21 to page 5, paragraph 26; page 6, 
paragraphs 27-29). (See also Figures 3a through 7 and the descriptions thereof on pages 4-8). 

F. VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Whether claims 1, 3-8, 10-20 and 22 are unpatentable under 35 USC 
Section 103(a) as obvious over U.S. Patent Application Publication No. 2004/0264397 Al by 
Benveniste in view of U.S. Patent Application Publication No. 2004/0103282 Al by Meier. 

2. Whether claims 2, 9, 21 and 23 are unpatentable under 35 USC Section 
103(a) as obvious over Benveniste and Meier in view of U.S. Patent Application Publication No. 
2003/0126244 Al by Smith et al. 

G. VII. ARGUMENT 

The Examiner initially bears the burden of establishing a prima facie case of 
unpatentability. In re Bell, 26 U.S.P.Q.2d 1529 (Fed. Cir. 1993); In re Oetiker, 
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977 F.2d 1443, 1445, 24 U.S.P.Q.2d 1443, 1444 (Fed. Cir. 1992); In re Piasecki, 
745 F.2d 1468, 1472, 223 U.S.P.Q. 785, 788 (Fed. Cir. 1984); MPEP § 2142. 

An obviousness rejection may be attacked by showing that the Examiner has 
failed to properly establish a prima facie case or by presenting evidence tending to support a 
conclusion of non-obviousness. In order to find prima facie obviousness when combining 
references, MPEP § 2143(A)(1) states the following (emphasis ours): "Office personnel must 
articulate the following: (1) a finding that the prior art included each element claimed , although 
not necessarily in a single prior art reference, with the only difference between the claimed 
invention and the prior art being the lack of actual combination of the elements in a single prior 
art reference." MPEP § 706.02(j) further states (emphasis ours): "To support the conclusion that 
the claimed invention is directed to obvious subject matter, either the references must expressly 
or impliedly suggest the claimed invention or the examiner must present a convincing line of 
reasoning as to why the artisan would have found the claimed invention to have been obvious in 
light of the teachings of the references. Ex parte Clapp, 227 USPQ 972, 973 (Bd. Pat. App. & 
Inter. 1985)." See also In re Thrift and Hemphill, 298 F.3d 1357, 1366 (Fed. Cir. 2002) (for an 
examiner to establish a prima facie case that an invention, as defined by a claim at issue, is 
obvious the examiner must: (1) show some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the art, to modify 
the reference or combine the reference teachings; (2) there must be a reasonable expectation of 
success; and (3) the prior art reference (or the combined references) must teach or suggest all the 
claim limitations); MPEP § 2142. Moreover, a reference must be viewed as a whole, including 
portions that would lead away from the claimed invention. MPEP § 2141.02 (citing W.L. Gore 
& Assoc., Inc. v. GarlocK Inc., 721 F.2d 1540, 220 U.S.P.Q. 303 (Fed. Cir. 1983). If the 
proposed modification would change the principles of operation of the prior art invention being 
modified, then the teachings of the references are not sufficient to render the claims prima facie 
obvious. MPEP § 2143.01 (citing In re RattU 270 F.2d 810, 123 U.S.P.Q. 349 (CCPA 1959)). 

The U.S. Supreme Court case, KSR Intl Co. v. Teleflex, Inc., 550 U.S. 398 
(2007), does not change the requirement for an examiner to provide such evidence of motivation. 
"The teaching or suggestion to make the claimed combination and the reasonable expectation of 
success must both be found in the prior art, not in applicant's disclosure." MPEP § 2143. The 
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level of skill in the art cannot be relied upon to provide the suggestion to combine the references. 
MPEP § 2143.01 (citing Al-Site Corp. v. VSI Int'l Inc., 174 F.3d 1308, 50 U.S.P.Q.2d 1161 (Fed. 
Cir. 1999). The mere fact that the references can be combined or modified does not render the 
resultant combination obvious unless the prior art also suggests the desirability of the 
combination. MPEP § 2143.01 (citing In re Mills, 916 F.2d 680, 16 U.S.P.Q. 2d 1430 (Fed. Cir. 
1990). 

A. Claims 1, 3-8, 10-20 and 22 Are Not Rendered Obvious by Benveniste 
in View of Meier 

Independent claim 1 recites, "[a] method to determine in a network component 
when to provide service to client devices operating in power-saving mode in a wireless network, 
said method comprising: receiving requests for service . . . including a scheduled request received 
from a first one of the client devices and an unscheduled request received from a second one of 
the client devices, said network component being informed of said scheduled request by a field 
of a traffic specification format being set to a first value, said network component being 
informed of said unscheduled request by said field of said traffic specification format being set to 
a second value different from said first value ." Independent claim 8 similarly recites, "said 
device being informed of said scheduled request by a field of a traffic specification format being 
set to a first value, said device being informed of said unscheduled request by said field of said 
traffic specification format being set to a second value different from said first value." 
Independent claim 18 similarly recites, "said network component being informed of said 
scheduled request by a field of a traffic specification format being set to a first value, said 
network component being informed of said unscheduled request by said field of said traffic 
specification format being set to a second value different from said first value." Independent 
claim 22 similarly recites, "become informed of the scheduled request based on a field of a 
traffic specification format being set to a first value; become informed of the unscheduled 
request by said field of said traffic specification format being set to a second value different from 
said first value." 

The Examiner concedes "said network component being informed of said 
scheduled request by a field of a traffic specification format being set to a first value, said 
network component being informed of said unscheduled request by said field of said traffic 
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specification format being set to a second value different from said first value" is not disclosed 
by Benveniste. 

The Examiner relies on the table appearing in Meier below paragraph 470, which 
is a table for a Subnet Context Manager Advertisement Reply Message, and to Unscheduled Flag 
Bit 14, which is set ON in unscheduled advertisement messages. The Examiner contends Bit 14 
is an unscheduled flag to indicate if the advertisement message is scheduled or unscheduled, and 
appears to contend this would have motivated the further modification to the combination of 
Benveniste and Meier to include in a client request a field indicating whether the request is for 
scheduled service or for unscheduled service . 

The Subnet Context Manager of Meier periodically transmits advertisement reply 
messages and access points (APs) discover the active SCM for a subnet by monitoring the 
advertisements. See Meier paragraph 387. It appears the unscheduled flag of Meier is set in an 
advertisement reply message when the message is in response to a node request for an 
advertisement message earlier than scheduled. The node sends such a request to shorten the 
discovery period for the active SCM. See Meier paragraph 388. Thus, the unscheduled field of 
Meier appears to indicate whether the advertisement is a periodic advertisement or a requested 
advertisement. This is not the same thing as a field of a traffic specification format which 
indicates whether a received client request is a request for scheduled service or a request for 
unscheduled service, and thus the combination of Benveniste with Meier would not alone 
achieve the claimed invention. Smith does not cure the deficiencies of Benveniste. Thus, 
Benveniste, alone or in combination with Meier and Smith, does not teach, suggest, motivate or 
otherwise render obvious a field of a traffic specification format which indicates whether a client 
request is a scheduled request or an unscheduled request. 

In the Final Office Action, the Examiner responds to the above arguments by 
emphasizing a difference between the combination of Benveniste and Meier and the claimed 
invention. Specifically, the Examiner emphasizes that Bit 14 of the advertisement message (a 
beacon) of Meier on which the Examiner relies indicates whether an advertisement message is a 
scheduled advertisement message or in reply to a request for an advertisement message. A field 
in an advertisement message transmitted by a client manager which indicates whether the 
advertisement message is a scheduled advertisement or a reply to a request from a node is not the 
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same thing as a field of a traffic specification format indicating whether a client request is a 
request for scheduled service or a request for unscheduled service. An advertisement message 
from an SCM of Meier is not a request for service and is not from a client. In other words, the 
Examiner has not shown that all of the elements of the claims are present in the combined 
reference. 

Thus, to show obviousness, the Examiner must present a convincing line of 
reasoning as to why one of skill in the art would have further modified the combination of 
Benveniste and Meier. This the Examiner has failed to do. Instead the Examiner employs 
impermissible hindsight reasoning: "[motivation to combine these references comes from an 
access point being able to differentiate between scheduled and unscheduled requests to provide 
increased QoS for scheduled requests since they are arranged in advance." This reasoning also 
appears to be contrary to the principles of operation of Meier. A request for an unscheduled 
advertisement is issued by a node of Meier to speed up the discovery process. If such requests 
are not honored before the next scheduled advertisement message from an SCM, the process of 
discovery would not be sped up. The Examiner also appears to contend that Benveniste already 
knows whether a client request is for scheduled or unscheduled service when it is received. 
Assuming the Examiner's interpretation of Benveniste is correct, there would be no motivation 
to modify Benveniste to include such a field in client requests. 

Claims 3-7 depend from claim 1, claims 10-17 depend from claim 8, and claims 
20 and 21 depend from claim 18. Accordingly, claims 1, 3-8, 10-18 and 21-22 are not rendered 
obvious by Benveniste alone or in combination with Meier. 

B. Claims 2, 9, 19 and 23 Are Not Rendered Obvious by Benveniste 
in View of Meier and Smith 

Claims 2, 9, 19 and 23 depend respectively from claims 1, 8, 18 and 22. The 
Examiner does not contend that Smith teaches a client request that includes a field indicating 
whether the client request is for scheduled or unscheduled service. Accordingly, claims 2, 9, 19 
and 23 are not rendered obvious by Benveniste alone or considered in combination with Meier 
and Smith at least by virtue of their dependencies. 
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C. Conclusion of Argument 

The Examiner has failed to establish a prima facie case that the claims are 
anticipated or rendered obvious by Benveniste, whether considered alone or in combination with 
Meier and Smith. Accordingly, the Examiner's rejections cannot be sustained and reversal of the 
Examiner's rejections is respectfully requested. 



Respectfully submitted, 

SEED Intellectual Property Law Group PLLC 



/Timothy L. Boiler/ 
Timothy L. Boiler 
Registration No. 47,435 

TLB:jrb 

701 Fifth Avenue, Suite 5400 
Seattle, Washington 98104 
Phone: (206)622-4900 
Fax: (206) 682-6031 

1495498 1 
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H. VIII. CLAIMS APPENDIX 



1 . A method to determine in a network component when to provide service 
to client devices operating in power-saving mode in a wireless network, said method comprising: 

receiving requests for service from respective ones of said client devices, the 
received requests for service including a scheduled request received from a first one of the client 
devices and an unscheduled request received from a second one of the client devices, said 
network component being informed of said scheduled request by a field of a traffic specification 
format being set to a first value, said network component being informed of said unscheduled 
request by said field of said traffic specification format being set to a second value different from 
said first value; 

determining an ability to accommodate said received requests for service; and 
providing respective indications of the ability to accommodate said received 
requests for service to the first and second ones of said client devices. 

2. The method as recited in claim 1, further comprising, in response to being 
unable to accommodate the unscheduled request, providing a proposed service schedule to the 
second one of the client devices. 

3. The method as recited in claim 1, wherein said scheduled request includes 
a proposed service schedule. 

4. The method as recited in claim 3, further comprising modifying said 
proposed service schedule. 

5. The method as recited in claim 4, further comprising providing said 
modified proposed service schedule to said first one of the client devices. 
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6. The method as recited in claim 1, wherein said indications are selected 
from a group consisting of: denied, accommodated with change, and accommodated. 

7. The method as recited in claim 1, wherein said determining the ability to 
accommodate is based on at least one factor selected from a group consisting of: a requested 
servicing method, a proposed schedule, network operating state, network policy, and network 
condition. 

8. A device to determine when to provide service to client devices operating 
in power-saving mode in a wireless network, said device comprising: 

a memory; 

a processor in communication with said memory, said processor operable to 
execute code to: 

receive requests for service from respective ones of said client devices, the 
received requests including a scheduled request received from a first one of the client devices 
and an unscheduled request received from a second one of the client devices, said device being 
informed of said scheduled request by a field of a traffic specification format being set to a first 
value, said device being informed of said unscheduled request by said field of said traffic 
specification format being set to a second value different from said first value; 

determine an ability to accommodate said received requests for service; and 
provide respective indications of the ability to accommodate said received 
requests for service to the first and second ones of said client devices. 

9. The device as recited in claim 8, wherein said processor is further operable 
to execute said code to, in response to being unable to accommodate the unscheduled request, 
provide a proposed service schedule to the second one of the client devices. 

10. The device as recited in claim 8, wherein said scheduled request includes a 
proposed service schedule. 
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11. The device as recited in claim 10, wherein said processor is further 
operable to execute said code to: modify said proposed service schedule. 

12. The device as recited in claim 11, wherein said processor is further 
operable to execute said code to: provide said modified service schedule to said first one of the 
client devices. 

13. The device as recited in claim 8, wherein said indications are selected 
from a group consisting of: denied, accommodated with change, and accommodated. 

14. The device as recited in claim 8, wherein said determine said ability to 
accommodate is based on at least one factor selected from a group consisting of: a requested 
servicing method, a proposed schedule, network operating state, network policy, and network 
condition. 

15. The device as recited in claim 8, further comprising: an I/O device 
operable as an interface between said network and said processor. 

16. The device as recited in claim 8, wherein said code is stored in said 

memory. 

17. The device as recited in claim 8, further comprising: 
a receiving device to receive said requests; and 

a transmitting device to provide said respective indications to the first and second 
ones of said client devices. 

18. A processor within a network component to determine an ability of said 
network component to honor requests for service received from respective client devices, said 
processor being configured to execute code to cause the network component to: 

review an operating state of said network component; 
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review said requests for service, the requests for service including a scheduled 
request received from a first one of the client devices and an unscheduled request received from 
a second one of the client devices, said network component being informed of said scheduled 
request by a field of a traffic specification format being set to a first value, said network 
component being informed of said unscheduled request by said field of said traffic specification 
format being set to a second value different from said first value; 

accommodate said requests for service, with modification when necessary, when 
said operating state indicates that said requests for service are able to be accommodated; and 

provide respective indications of said accommodation to said first and second one 
of the client devices. 

19. The processor as recited in claim 18, wherein said processor is further 
configured to execute code to cause the network component to: 

provide respective indications of denying said requests for service to the first and 
second ones of the client devices when said operating state indicates that said requests for service 
are unable to be accommodated. 

20. The processor as recited in claim 18, wherein said operating state is 
selected from a group consisting of: processing load, demand, projected processing load, 
projected demand, network component operating state, network component policy, and network 
component condition. 

21. The processor as recited in claim 18, wherein said processor is further 
adapted to execute code to cause the network component to, in response to being unable to 
accommodate the unscheduled request, provide a proposed service schedule to the second one of 
the client devices. 

22. A computer readable media whose contents cause a processor to execute 
instructions to cause a network component to: 
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receive requests for service from client devices, the received requests including a 
scheduled request received from a first one of the client devices and an unscheduled request 
received from a second one of the client devices; 

become informed of the scheduled request based on a field of a traffic 
specification format being set to a first value; 

become informed of the unscheduled request by said field of said traffic 
specification format being set to a second value different from said first value; 

determine an ability to accommodate said received requests for service; and 

provide respective indications of the ability to accommodate said received 
requests for service to the first and second ones of said client devices. 

23. The computer readable media of claim 22 wherein execution of the 
instructions further causes the network component to, in response to being unable to 
accommodate the unscheduled request, provide a proposed service schedule to the second one of 
the client devices. 
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EVIDENCE APPENDIX 
None. 



RELATED PROCEEDINGS APPENDIX 
None. 
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